Store provider credential overrides encrypted in the database - #492

Fail loudly instead of silently unconfiguring providers. An Infisical read
that succeeds but returns nothing is an outage, not an empty credential set,
so the loader throws and the overlay keeps its last good values. Misread keys,
undecryptable rows and vanished credentials log errors with the action to take.

Take Infisical off the web request path. The cloud web app runs on Vercel
serverless, where a runtime read would add an authentication round trip to
every cold start and put Infisical in front of the whole site; Infisical's
Vercel secret sync populates the environment at deploy time instead. Only the
worker, which is long-lived and spends against these credentials, keeps the
SDK loader — so the Infisical vars are no longer web startup requirements.

Read one Infisical folder rather than recursing from the project root, so the
machine identity needs no broader grant and two folders cannot both define
OPENAI_API_KEY with no defined winner.

Drop what the payload does not need: typ and v leave the JWE header, since ctx
is what stops a ciphertext being re-homed onto another provider. Drop the hint
column, which stored the last four characters of the longest value in a
bundle — the password, for Oxylabs and DataForSEO — in plaintext beside the
ciphertext, and which nothing reads.

Delete the unused dataforseo client that captured credentials from the
environment at module load.

The worker loads credentials before pg-boss starts, so a source that throws
took the whole worker down. On an upgrade that source is a fresh query against
provider_credentials, which fails if the database is briefly unreachable or not
yet migrated — and the compose file only guarantees migration ordering when
Postgres runs in Docker.

Schedule the retry interval before the first load and let self-hosted modes
carry on with their .env credentials when that load fails. Managed cloud still
rethrows, since it has no environment fallback and a worker that started anyway
would only take jobs it cannot run. This also fixes the web path never retrying
after a failed initial load.

Only the worker reads them at runtime, but treating them as worker-only let a
cloud deployment go out with a worker that had no way to reach Infisical. Make
them cloud requirements again so that misconfiguration surfaces at startup.

INFISICAL_SECRET_PATH and INFISICAL_SITE_URL stay optional — both have working
defaults, and requiring the site URL would break any deployment relying on the
US cloud default.

@infisical/sdk depends on @aws-sdk/credential-providers and @smithy/*, and Nitro
traces a dynamic import into the output whether or not the branch can run. The
cloud web app never loads credentials over the network, so that was megabytes of
AWS SDK shipped into a Vercel serverless function that would never call it.

Move the worker's source selection into its own entry point. startCredentialRefresh
now takes a source and whether it is required, so the module the web app imports
only ever references instanceCredentialSource.

Tracing the import graph from apps/web/src/server.ts no longer reaches
@infisical/sdk; from apps/worker/src/index.ts it still does.

Both only ever held their defaults, and each was another way for a cloud
deployment to point the loader somewhere the credentials are not. Read the root
of INFISICAL_ENVIRONMENT on Infisical's US cloud, with no way to override
either.

With the read already non-recursive, that fixes the folder contract in one
place: one flat set of canonically named secrets at the environment root, and
nothing else in the project is fetched.

Infisical reaches both cloud runtimes through secret syncs, which land the
provider credentials in each platform's environment. The app needs no
Infisical client of its own: getCredential already falls through to
process.env, and with no ELMO_ENCRYPTION_KEY there is no store to consult,
so cloud is pure environment with no deployment-mode branching at all.

That removes the reason the refresh loop lived in @workspace/deployment, so
it moves to @workspace/lib/secrets alongside the store it drives.

Storage is keyed by the environment variable a secret overrides rather than
by provider, since a provider is not the unit anyone edits — brightdata
needs a login and a password, and grouping them only forced a bundle
protocol on top of what is really a per-variable override.

`elmo init` generates the key and the CLI backfills it on upgrade, so every
self-hosted deployment has one — validating it makes that guarantee visible
instead of leaving a deployment silently unable to store credentials. The
hosted modes are provisioned out of band and keep no store of their own, so
the requirement is scoped to local.

A JWE names its own algorithms, so the allowlist on decrypt is what stops a
row re-encrypted under a weaker one from being honoured. Nothing covered it.

Also retires the provider-shaped AAD strings the crypto tests still used.

Without a key id there was no rotation path: a payload could not say which
key it belonged to, so the store could not tell a rotated key from a corrupt
row, and changing the key stranded every existing secret with no way back.

ELMO_ENCRYPTION_KEY still encrypts, and the comma-separated
ELMO_ENCRYPTION_KEY_OLD stays readable, so a rotation is a restart rather
than a re-entry of every credential. A row naming a key nobody holds now
reports that key instead of blaming the payload.

The id is a domain-separated SHA-256 of the key, truncated — self-describing,
so a key identifies itself with nothing to configure and nothing to keep in
sync. Selecting on it is safe: the header is the AEAD's additional data, so a
rewritten kid fails the tag rather than steering the payload somewhere it
decrypts.